Thanks for working on this @MattOz-CDS.
Out of interest, is there a reason we can't make this an event for the existing LGD page header?

Have done a quick test. I can see the header block displayed. It shows the header block and the description entered in the user description field.

This works on direct forms. Not yet tested on forms embedded in a node (which is a technique BHCC use to get the lede).

I also noticed that when enabled, it's not possible to paginate when AJAX page switching is turned on.
It's also not the block positioning that determines if it is visible. I tried it by placing the block, but that's not what determines if this is placed. It's exclusively the switch in the webform settings. As a site builder this could be confusing, and generally I would imaging that we would generally want to have the pattern for all forms or none.

Thanks for working on this @MattOz-CDS. Out of interest, is there a reason we can't make this an event for the existing LGD page header?

Hi @andybroomfield, I hope all is well. Thanks for testing this, it's much appreciated.

Initially I wasn't sure, so my approach was to use the 'LGD Page Header' event as a template for how the form header event should be written. I thought that If we keep them separate, we would:

• Define a 'Specificity of Purpose' - Form Headers for forms and Page headers for pages. The 'FormHeaderDisplayEvent' is specifically designed to handle the display of headers for forms, particularly webforms, and includes properties like 'formTitle', 'wizardPageTitle', and 'currentPage', which are unique to forms. The 'LGD PageHeaderDisplay' event might have a broader or different purpose, such as handling generic page headers across the site, which may not require form-specific properties.
• Avoid overloading the LGD Page Header event with additional form related logic which would increase complexity and possibly make it harder to understand.
• Make the codebase easier to understand and maintain. Keeping the events separate ensures that each event is focused on its specific task and would make it clearer for developers to know which event is responsible for what. Also, if the requirements for form headers and generic page headers diverge in the future, having separate events allows us to evolve them independently without introducing breaking changes to one or the other.

However, there maybe a better, simpler way. You may be seeing something I can't. Please share your thoughts as I'm always open suggestions.

Thanks @andybroomfield. You're observations and tests have highlighted that this is definitely not the correct approach. I've worked out how this can be achieved by subscribing to the existing Page Header Display event. Closing this down.